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ABSTRACT 


The objective of the Software Design and Documentation Language 
(SDDL) is to provide an effective communications medium to support 
the design and documentation of complex software applications. This 
objective is met by providing (1) a processor which can convert design 
specifications into an intelligible, informative machine-reproducible 
document, (2) a design and documentation language with forms and syntax 
that are simple, unrestrictive , and communicative, and (3) methodology 
for effective use of the language and processor. 

The SDDL processor is written in the SIMSCRIPT II programming 
language and has been implemented on the UNIVAC 1108 and the IBM 360/870 
machines. 
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SECTION I 
INTRODUCTION 


The frontispiece is a conceptual view of the software development 
process. It identifies members of the software development team and 
shows the many communication links over which information must flow. 

The team members and the information flow shown in the diagram are 
a part of every software development project regardless of the number 
of individuals actually involved. Even when the entire task is done 
by a single person, it is still essential to have precise, accurate, 
orderly communication among the various roles the individual performs. 
With orderly communication, decisions made last month can be acted 
upon correctly this month, and valid information will be available 
later when maintenance responsibilities may have to be assumed by others. 

The diagram also suggests that a computer programming language 
is a satisfactory communications medium for only a few links; primarily 
between programmer and machine, and secondarily among programmers. 

All other higher-level team communication requires less restrictive, 
more human-oriented media to be effective . 

Historically, software development has suffered because of the 
lack of an effective communications medium for these high-level links. 

One may generalize that everyone has experienced some painful results 
of imprecise and/or incomplete communication in every aspect of life. 
Programmers suffer immediately when imprecise, incorrect, or incomplete 
directions are executed by the computer exactly as stated. Managers 
and customers are affected more seriously because bad communications 
at the design stage may compound the error by allowing the programming 
effort, with all its problems, to proceed toward an elusive or erroneous 
goal. 


As long as the communication between members of the 
software development team remains fuzzy, the misunderstanding will 
continue and software development costs will be higher than they need 
be. Software maintenance gets into the act later, when maintenance 
programmers must deal with poorly written, out-of-date documentation, 
which, by Murphy's Law, is certain to.be inconsistent where it matters. 

Effective communication is not sufficient to insure efficient 
software development, but it is certainly necessary. Therefore, the 
Software Design and Documentation Language (SDDL) has been developed 
to satisfy this necessity. 


A. SDDL OBJECTIVE 

The objective of SDDL is to satisfy the coiomunications requirements 
of the software design and documentation process. This objective is 
met by providing 
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(1) A processor which can convert design specifications into 

an intelligible, informative, machine-reproducible Software 
Design Document (SDD), 

(2) A program design and documentation language with forms 

and syntax that are simple, unrestrictive , and communicative. 

(3) A methodology for effective use of the language and the 


B. SDDL PROCESSOR 


The purpose of the SDDL processor is to translate the designer's 
crea ive thinking into an effective communications document. The processor 
mu.t perform^ as many automatic functions as possible, thereby freeinr 
the designer s energy for the creative design effort. 

state automatic functions which the processor, in its current 

state of development, performs are listed below. 


Document Formatting 

(1) Indentation by structure logic. 

(2) Flow lines for accentuating structure escapes. 

(3) Flow lines for accentuating module invocation. 

(4) Line numbering and/or card sequencing for input deck editing. 

(5) Logic error detection. 

(6) Special handling for title pages and text segments. 

(7) Input and output line continuation. 

(8) Line splitting (i.e., printing part of the line so that 
the last character lines up at the right-hand margin). 

Software Design Summary Information 

(1) Module invocation hierarchy. 

(2) Module cross reference (where each module is invoked). 

(3) Cross reference tables for selected words or phrases 

shearing in the document. Selection is controlled by 
the user . ^ 
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(4) Table of contents showing all titles and modules, and the 
location of the tables described above. 

(5) Page reference numbers on module invocation statements. 


Processor Control Capabilities 


(1) 

Page width. 


(2) 

Structure indentation amount. 


(3) 

Page ejection. 


(4) 

Input line numbering sequence. 


(5) 

Keyword specification. 


(6) 

Selection of words for inclusion 
tables. 

in the cross reference 

(7) 

Number of right-hand columns for 

card sequence numbers. 

(8) 

Execution time options for suppressing selected processor 
features. 


C. SDDL OVERVIEW 

1 . SDDL Syntax 

The SDDL syntax consists of keywords , used to invoke design 
structures, and a collection of directives , which provide the user with 
control of processor actions such as indentation, page width, start 
of a new page, etc. Execution time options allow the user to selectively 
suppress design summary information. 

Input to the SDDL processor consists of a sequence of SDDL statements. 
An SDDL statement begins and ends with a line (or record) of the input 
medium, unless continuation is explicitly indicated by placing an ampersand 
(4) in the last non-blank character of the line. Continued lines 
are concatenated into a single statement for processing. Any natural 
language text, including a blank line, is an acceptable SDDL statement. 
Keywords are recognized only in context, that is, only when they appear 
as the first word of the input statement. 

The user is provided complete control of the choice of keywords 
by an SDDL directive which allows unlimited addition or deletion of 
keywords. User control of keyword selection is one of the most important 
features of SDDL because it allows the designer to command the capabilities 
of the processor in the way which is best suited to communicating the 
intent of the design. 
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A complete description of the SDDL semantics is given in Section II 
and summarized there in the SDDL Syntax Overview diagrams. 


2 . SDDL Structures 

The basic forms of the language are the module and block structures, 
and the Module Invocation statement. A design is stated in terms of 
modules that represent problem abstractions which are complete and 
independent enough (relative to the level of the design) to be treated 
as separate problem entities. Modules are the highest-level structure. 

They may not be nested. Descriptive names are given to the modules, 
and their interrelationships are stated explicitly by the Module Invocation 
statements. A Module Invocation statement is the equivalent of the 
subroutine CA.LL statement in a programming language . 

Blocks are the lower-level structures. They are used to build 
representations of abstractions which should (relative to the specific 
design) be a part of and appear with the higher-level abstraction 
represented by the module. Thus blocks must be nested within modules 
and may be nested within other blocks to any reasonable (i.e., 
understandable) depth. Examples of the use of blocks are the 
representa. ions of Structured Programming concepts such as IF-THEN- 
ELSE and LOOP-REPEAT. 

Both kinds of structures may have up to four parts: 


(1) 

Initiator 

(required) 

(2) 

Terminator 

(optional ) 

(3) 

Escape 

(optional) 

(4) 

i 

Substructure 

(optional) 


Structure parts are specified by statements which begin with a keyword 
that has been defined as the part name. Table 1 displays the SDDL 
default keywords lor both kinds of structures and their corresponding 
structure parts. 

The actions taken by the processor in response to keyword statements 
are fully explained in Section II and summarized in Figure 1. These 
actions are quite simple but very effective for communicating design 
information. Indentation of statements within structures, and flow 
lines to highlight structure escapes and module invocations provide 
visual, two-dimensional information display which captures all of the 
advantages offered by flowcharts without their attendant disadvantages 
and constraints. 

A simple illustration is presented following Figure 1 . 
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Table 1—1 . SDDL Control Structure Keywords 


MODULE 

INITIATOR 

TERMINATOR 

ESCAPE 

SUBSTRUCTURE 

PROGRAM 

ENDPROGRAM 

EXIT PROGRAM 


PROCEDURE 

ENDPROCEDURE 

EXITPROCEDURE 


BLOCK 

IF 

ENDIF 


ELSE 

ELSEIF 

SELECT 

ENDSELECT 



LOOP 

ENDLOOP 

REPEAT 

EXITLOOP 

CYCLE 


CALL 

CALL 

DO 

N/A 

N/A 

N/A 

PROCESSOR 

CONTROL 

0 LINENUMBER 

# EJECT 

0 INDENT 

# DEFINE 
IMARK 
#WIDTH 
^STRING 
#SEQUENCE 
#TERMINATE 




# TITLE ] 

#TEXT I 

0 END 
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Figure 1-1 . SDDL Procesaor Actions 
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In most of the following examples, the SDDL input statements 
are shown with the resulting output produced by the processor. In 
practice, the input source listing is rarely needed. Where the source 
statements are shown, as in the example below, it should be understood 
that the line numbering, including the colon, was added and is not 
part of the input statement. 

Example : 


As input: 


1 

2 
3 

5 

A 

7 

8 
9 

10 

11 

12 

13 

IH 

15 

16 

17 

18 

19 

20 
21 
22 
23 
2H 

25 

26 

27 

28 

29 

30 

31 

32 

33 
39 

35 

36 

37 

38 

39 
^0 
^1 

92 

93 
99 


PROGRAM example TO DEMONSTRATE tHe BASIC SDOL STRUCTURES 

(THE line above IS A MqoULE INItUTOR STATEMENT WHICH ESTABLISHES 

"example" as THE NAME OF THIS PrOgRAM/MOOULE 1 

IF this condition is true (BLOCK INITIATOR "IF"1 
ACT ON jHIS STATEMENT (PASSIVE StaTEHENT> 
else (SUBSTRUCTURE STATEMENT F0« "IF") 

ACT ON the following STATEMENTS jANOTHeR PASSIVE STATEMENT) 

LOOP For Index • ) to something (Block initiator "loop") 

(PASSIVE statements can be placed ANYWHERE) 

CALL subroutine ( MoOUle INVOCATION STATEMENT) 

THE name of the MODULE INVOKED iN THE PREVIOUS STATEMENT 
IS "SUBROUTINE" 

IF there Is nothing left to do (nested Block initiator "if") 
EXITLOOP (ESCAPE STATEMENT "LooP" 1 
ENDIF (TERMINATOR STATEMENT 9 (ESTeD "IF") 

endloop (terminator Statement "Loop") 


ENDiF (TERMINATOR STATEMENT "If") 
ENOpKOGRAM (MODULE TERMINATOR STATEMENT 

procedure subroutine 


’PROGRAM" ) 


note; a module initiator statement causes THE START OF A NEW PAGE< 

select case based on Some criterion (block initiator "select") 

case 1; check for subroutine abort (SUBSTRUCTURE STATEMENT FOR "SELECT") 
IF there Is no 
EXItPROcEOURE 
ENDIF 


more data TO BE read (BLOCK INITIATOR "IF") 
(ESCAPE statement "PROCEDURE") 


case 2; check FOR subroutine error (SUBSTRUCTURE STATEMENT FOR "SELEcT") 
IF an error occurs (Block initiator "if") 

PRINT AN ERROR MESSAGE (PASSIVE STATEMENT) 

ENDIF 

CASE 3; INVOKE ANOTHER SUBROUTINE (SUBSTRUCTURE STATEMENT FOR "SELECT") 

DO another subroutine (Module invocation statement) 
note; "DO" IS A synonym FOR "call" (PASSIVE STATEMENT) 

enDseLect (Terminator statement "Select") 

ENOpROCtOURE (MODULE TERMINATOR STATEMENT "PROCEDURE") 
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As output: 


paqe 

NUMBER 


Table of contents 


PA«e I 


L 1 ME ♦♦♦♦♦♦♦ + ♦*♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ 

NUMBER module NAME 


1 I PROGRAM EXAMPLE TO DEMONSTRATE THE BASIC SOOL STRUCTURES 

2 23 procedure SUBROUTINE 

3 Module reference tree 

H module - CRDSS reference listing 


line I 

1 PROGRAM example TO OeMqNStRATE TMe 8aS|C SODL STRUCTURES 

2 ITHe line above IS A MODULE INITIATOR STATEMENT WHICH ESTABLISHES 

3 "example" as the name OF THIS PrOgRAH/MOOULE 1 
H 

5 IF this condition IS TRUE JBLOCX INITIATOR "IF") 

6 act oN this statement (PASSIVE STATEMENT) 

7 else (SUBSTRUCTURE STATEMENT FoR "IF") 

8 ACT oN the following STATEMENTS (ANOTHER PASSIVE STATEMENT) 

9 

10 LOOP For index • I to somethin^. (bLOCx initiator "LOOP") 

u (PASSIVE statements CAN 8E PLACED ANTWHERE) 

12 Call subroutine (module invocation statement)— ————>( 2» 

13 THE name OF THE MODULE INVOKED IN THE PREVIOUS STATEMENT 

m is "subroutine" 

15 IF there is nothing LEFT TO 00 (NESTED BLOCK INITIATOR "IF") 

14 EXITLOOP (ESCAPE STATeMeNT "LOOP") 

17 EnDIF (TERMINATOR STATEMENT NESTED "IF") 

18 ENOLoOP (TERMINATOR STATEMENT "LOOP") 

19 

20 ENDIF (TERMINATOR STATEMENT "if") 

21 ENOPROGRAM (MODULE TERMINATOR STATEMENT "PROGRAM") 
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line 

23 PROCEOUfiE SUBROUTINE 


PAU 2 


2H 

25 

26 

27 

28 

29 

30 
3t 

32 

33 
3H 

35 

36 

37 

38 

39 

90 

91 

92 

93 
99 


notc: a hooule initiator statement causes the start or a new pace* 

Select case based on some criterion (block initiator *selcCt*i 

case !• check for subroutine abort (SUBSTRUCTURE STATEMENT FOR "SCLECT*! 
IF THERE IS NO MoRE DATA TO BE READ (BLOCK INITIATOR "IF") 

EX ITPROCEOUrc (ESCAPE StaTeMENT "PROCEDURE") 

ENDlr 

CASE 2: check for subroutine error (SUBSTRUCTURE STATEMENT FOR "SELECT") 

IF AN ERROR OCCURS (BLOCK INITIATOR "IF") 

Print an error messase (passive statement) 

ENDlr 

CASE 3; invoke another subroutine (SUBSTRUCTURE STATEMENT FOR "SELECT") 
OO another subroutine (MODULE invocation STATEMENT ) -•--••••-••>( ) 

NOTE: "DO" IS A synonym FOR "cALL" (PASSIVE STATEMENT) 

enoselect (Terminator statement "Select") 

ENOPROCEOURE (MODULE Tf.RNiNATOR STATEMENT "PROCEDURE") 


! 

1 

! 

I 


*••••#•••»•«•• MODULE reference TREE 
LN PAGE 

1 I example 

2 2 « SUBROUTINE 

3 • « • another 


module , _ 

CROSS reference listing page 9 

lOENTiF lER***^**<“ + **^****^*********'*'*^**^*‘**^*********'*'***^***'^*^**************^ 


ANOTHER 

PAGE 2 procedure SUBrOUjINe 

lines 90 

example 

PAGE I program example 

LINES It 3 

subroutine 

PAGE I program example 

LINES 12, 19 

PAGE 2 PROCEDURE SUBROUTINE 

LINES 23, 29, 39, 39, 90 


1-9 


1 1 t !a K 


77-24 


D. SDDL METHODOLOGY 

The following discussion of techniques and styles is intended as 
a guideline or list of suggestions for using the capabilities of the 
SDDL language and processor to fullest advantage in striving for the 
goal of an informative and communicative Software Design Document. 

The reader is encouraged to excimine these suggestions with a 
critical eye. Accept what is useful, adapt to your own requirements 
and taste, and invent new methods, but always keep in mind that the 
primary purpose of the Software Design Document is to communicate 
information to other people. 


1 . Uses of the Software Design Document 

Throughout the development of the software design, the SDD always 
represents the definitive word on the current status of the ongoing, 
dynamic design development process. It is easily updated and readily 
accessible, in a familiar. Informative, readable form, to all members 
of the development team. This makes the SDD an effective instrument 
for reconciling misunderstandings and disagreements in the evolutionary 
development of design specifications, engineering support concepts, 
and the software design itself. Using the SDD to analyze the design 
makes it possible to eliminate many errors which otherwise might not 
be detected until coding is attempted. 

As a project management aid, the SDD is very useful for monitoring 
progress and for recording task responsibilities. 

The SDD has been found to be very effective in its primary role 
as the specification for coding the design. To date, there is no experience 
with the use of the SDD for software maintenance, but since the SDD 
is easily revised, and revisions are automatically cross referenced, 
the outlook for this purpose is favorable. 


2. Representation of Data Structures 

A thorough knowledge of the content and organization of its input 
and output data is an essential prerequisite to understanding a program. 
For this reason, much attention was focused on developing data structure 
representations that effectively display data organization and content. 
SDDL techniques that facilitate achieving this goal include; 

o Group the data into appropriate data description modules located 
in the beginning pages of the SDD. 

0 Provide descriptive names for variables. 

o Use the period (.) (it lies low on the printed line and does 
not interfere with readability) to connect the words of a 
descriptive phrase to form a variable name. 
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0 Use the underscore to connect the words of a descriptive phase 
to form a module name. 

0 Use the single or double quote mark to identify single word variable 
names for cross referencing. 

o Include information about the data (e.g. , units, mode, dimension, 
etc . ) in the data structure module . 

0 Group all data which describe attributes of a design entity with 
the entity they describe, and provide an entity name which can be 
used as a qualifier with the attribute. 

o If the program is to be implemented in a language that does 
not permit the use of descriptive variable names, include the 
name to be used in the program code in the data structure. 

o Define ENTITY (or another suitable word) to be a block initiator 
keyword to provide automatic indentation. Use the #TERMINATE 
directive to terminate the block without printing a Termination 
statement . 

Example : 


PROGRAM VEHICLE_COMPONENTS DATA 

STRUCTURE 


ENTITY ENGINE; 



PCT. PEDAL 

[PCTPED] 

PERCENT 

•RPM’ 

[ENGRPM] 

REV /MIN 

' TORQUE ' 

[TORQUE] 

FT«LB 

MIN .TORQUE 

[MINTOR] 

FT«LB 

MAX. TORQUE 

[MAXTOR] 

FT«LB 

•HORSEPOWER’ (VECTOR) 

[HPOWER] 

HP 


ENDPROGRAM VEHICLE_COMPONENTS DATA STRUCTURE 
PROGRAM DYNAMIC_SYSTEM_PARAMETERS DATA STRUCTURE 


ENDPROGRAM 


3. Representations of Control/Procedural Structures 

The constructs of Structured Programming, such as modules (e.g., 
PROGRAM - RETURN - ENDPROGRAM), iterations (e.g., LOOP - CYCLE/EXITLOOP - 
REPEAT), conditionals (e.g., IF - ELSE - ENDIF), and selections (e.g., 
SELECT - CASE - ENDSELECT) are used in a similar manner for software 
design. The difference is that for software design, the structures 
should convey human-oriented, natural language information to the 
level of precision and completeness necessary to communicate the design, 
but free of the syntax constraints and detailed information requirements 
imposed by programming languages. 
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Example: Module and block structures, high-level statements 

I PROGRAM MAIN ROUTINE 
LOOP UNTIL THERE IS NO MORE DATA 

READ THE DATA AND CHECK IT 
IF THE DATA IS BAD OR INCOMPLETE 

< CYCLE TO THE NEXT CASE 

ELSE 

CALL DATA_PROCESSING ROUTINE > (9) 

ENDIF 
REPEAT 

10 TERMINATE THE PROGRAM 

I I ENDPROGRAM 


o 


If the design must specify a list of conditions where all must 
tested and acted upon if true (in contrast to the SELECT-CASE- 
ENDSELECT construct, which finds and executes only the first true 
condition), a new structure is recommended in place of a sequence of 
IF-ENDIF structures. Use the #DEFINE directive to establish 
the following structure; 


CHECK - block initiator 
ENDCHECKLIST - block terminator 
CONDITION - substructure 


Example: 

As input: 


i:*oEfine bloc< check, enochecklist* . condition 

z • 

aiPROGRAM For vacation preparation 

5 ICHECK and act QN ALL TrUE CONDITIqNS IN THE FOLLOWING LIST 
6 : 

7 ;conoition: car needs To be serviced 
B:TAKe car to the service station 
9 :get gas and oil 

IOIINFlATE tires 

1 1 s 

i 2 ;condition; deliveries have to be cancelled 

13 ICANCEL newspaper 
IMICANcEL milk 
15 # 

uicondITion: trip has to be planned 
17 ;get haps 

isihake hotel reservations 

19 : 

20 JENDcHECKLIsr 

21 IENDpROGrAM 
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As output: 


line 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 


page 

prograh For vacation preparation 

CHECK AnD act on ALL TRUE CONDITIONS IN THE FOLLOWING LIST 

condition: car needs To be serviced 
take car to the service station 
get gAS and oil 
inflate tires 

condition: deliveries have to be cancelled 
cancel newspaper 
cancel hilk 

condition: trip has to be planned 
GET maps 

make hotel reservations 

ENDCHECkLIST 

Eli^OPROGRAM 


The following forms are recommended for use when the design has 
progressed to the point where engineering calculations need to 
be expressed: 


Example 1 : Equation not yet determined 

CALCULATE VEHICLE. STATE: DISTANCE. TRAVELLED (TARGETTED) 

• GIVEN: VEHICLE. STATE; DISTANCE. TRAVELLED (CURRENT) 

• VEHICLE. STATE. VELOCITY (CURRENT) 

• VEHICLE. ST ATE. ACCELERATION (TARGETTED) 

• TIME INCREMENT 


Example 2: Equation included 

COMPUTE VEHICLE. STATE; DISTANCE. TRAVELLED (TARGETTED) s 
D ♦ V»T + (A/2)»T»»2 

D s= VEHICLE. ST ATE; DISTANCE. TRAVELLED (CURRENT) 

V s= VEHICLE. STATE: VELOCITY (CURRENT) 

T == TIME. INCREMENT 

A ss VEHICLE. STATE: ACCELERATION (TARGETTED) 

Indentation in the examples above may be Imposed by indenting the input 
statements or by defining COMPUTE to be a Block Initiator keyword. 
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4. Specification of Module Interfaces 

Explicit specification of the data passed between modules and 
accessed from a global store will eliminate many debugging problems 
in the coding and integration stages. 

0 Use the words GIVEN and YIELD to specify parameters transmitted to 
and returned from a module. Use the word USING to specify global 
variables accessed. 

o List the GIVEN and YIELD parameters with Module Invocation 
statements. 

Example: 

NOW CALCULATE_DRIVE_WHEEL_OUTPUT_REQUIRED > ( 38) 

• GIVEN: VEHICLE. ST ATE: 

• SCHEDULED .TIME 

• YIELD: VEHICLE. STATE: TIRE.RPM, ACCELERATION 

• WHEEL FORCE REQUIRED 

» WHEEL TORQUE REQUIRED 

In this example, NOW is the Module Invocation keyword. Th: lines 

specifying arguments passed to and from the module all begin with an 
asterisk to emphasize their association with the Invocation statement . 

o List USING, GIVEN, and YIELD parameters with Module Initiator 
statements. 

Example: 

PROCEDURE TO CALCULATE_DRIVE_WHEEL_OUTPUT_REQUIRED 


USING; DRIVE. POWER. TRAIN: DATA 
CHASSIS: DATA 
GIVEN; VEHICLE. STATE: 

SCHEDULED. TIME 

YIELD; VEHICLE. STATE: TIRE.RPM, ACCELERATION 
WHEEL FORCE REQUIRED 
WHEEL TORQUE REQUIRED 


The parameters in this structure are set off by using the 
#TEXT - #END directives to enclose them in a box formed by asterisks. 
In addition to the GIVEN and YIELD arguments, the USING category lists 
global parameters which are accessed by the module. 


5. Inclusion of Management Information in the SDD 

Project management information. Just as program design, must 
be kept up to date and accurate. The SDD is the ideal place to maintain 
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this information, and the language can be used effectively to present 
the information. Listed below are several Module Initiator statements 
which have been used effectively in the VEEP and SAMIS programs. These 
examples are intended to suggest kinds of management information, as 
indicated by their wording, which might be included in the SDD. 

PROGRAM OBJECTIVES 
PROGRAM REVISIONS MEMORANDA 
PROGRAM MEETING CALENDAR & AGENDA 
PROGRAM DOCUMENT READING CONVENTIONS 
PROGRAM COMPLETION SCHEDULE 


6. Additional Uses of the Cross Reference Capability 

The SDD typically will contain much information, in addition 
to the names of design parameters, for which it would be useful to 
have a cross reference. Individual cross reference tables for each 
type of information can be obtained by associating a different cross 
reference title with each (see the #MARK directive). Some that have 
proved to be useful appear below in a sample design, showing the form 
of the #MARK directive which establishes the cross reference charac- 
ter, and the way in which the data appear in the main body of the SDD. 
The pound sign (#) has been used in the input to cause some information 
to be printed at the right-hand margin of the SDD for increased 
readability. 


Example : 

As input: 

i:«mark revisions * footnotes C file names 8 
2:«mark Update responsibility ? 

3;PR0gRAM to process customer data « CREF13 
r;REA0 names from CustOMeRSFILE s *1 
SIMATCH N*Mes to credit data • ?HK 
ainrite Credit info to creDItipile « »2 
7:enoprogram 
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As output: 


TABLE OF contents PAGe 1 

PAGE line 

number number module name 

1 3 PROGRAM TO PROCESS CUSTOMER DATA CREFjJ 

2 Revisions - cross reference listing 

3 footnotes - cross reference listing 

H file names - cross reference listing 

5 update responsibility - CROSS reference listing 


3 program to process customer data 
H read names from CUSTOMeHAFILE 

5 match Names to credit data 

6 WRITE Credit info to creoItsfile 

7 ENDPROGRAM 


PAGE 1 
CREFi 3 
%l 
?hk 


revisions 

CROSS reference listing page ^ 2 


%\ 

PAGE 

I PROGRAM 

TO 

PROCESS 


LINES 

H 



%2 

PAGE 

1 PROGRAM 

TO 

PROCESS 


LINES 

6 
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footnotes 

CROSS reference LIStINv. J 

lOENT IF ICR ♦♦♦♦♦♦ ♦♦♦♦'^■^^^* ********** **^***^^*^^*****^****^^****^**** 


CREFl 

PACE I program to process 
LINES 3 


file names 

CROSS reference listing 


PAGE 




CREOITfFILE 
PAGE 1 
LINES 6 
customersf ile 
PAGE I 
LINES 4 


program to process 


program to process 


update responsibility 
cross reference listing RA'iE 

lOENT IF lER 


?HK 


PAGE 

LINES 


\ program to PROCESS 

5 
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SECTION II 

SDDL USER'S REFERENCE GUIDE 


Input to the SDDL processor consists of a sequence of design state- 
ments and processor contiol directives. 

Statements and Directives begin and end with a line (or record) of 
the input medium, unless line continuation is explic..tly indicated, as 
described below. Continued lines are concatenated into a single statement 
for processing. 


A. CONTINUATION OF INPUT LINES 

A continuation mark, the ampersand can be used to concatenate 
several input lines/cards into a single SDDL input statement. The 
following rules apply to its use: 

(1) If the last non-blank character (excluding card sequence numbers 
— see #SEQUENCE directive) of an input line is an ampersand, 
the processor will concatenate the next line of input with 

the current line to form a single statement. 

(2) The ampersand which caused the continuation is removed 

from the newly formed line, but all other characters, including 
other ampersands and blanks, are used as they were input 
to form the new line. 

(3) The continuation mark may be used on as many subsequent 
input lines as desired to form a single SDDL statement 
or directive out of several input lines. 

(4) If the resulting input statement exceeds the allowable 
output line space, it will be handled as described below. 


B. CONTINUATION OF OUTPUT LINES 

Occasionally a line of output may be long enough to extend beyond 
the right-hand page margin. When this occurs, the processor handles 
the line in the following way: 

(1) Beginning at the appropriate indentation level, as many 
characters (including blanks) of the input line as space 
permits are printed on the current line. 

(2) On the next line of the document, an ampersand is printed 
one space to the right of the current indentation level, 

amd the remaining characters are printed immediately following 
the ampersand. Step 2 is repeated as many times as necessary 
to complete the line. 
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(3) If the Indentation level Is such that no characters can 

be printed on the first line, then step 2 is repeated with 

output beginning at the left margin instead of at the indentation 
level. 


Example : 

As input: 

1 PRIOR LINE 

2 THIS IS AN EXAMPLA 

3 E OF A LONG INPUT A 

4 LINE A A LONG OUTPA 

5 UT LINE 

6 NEXT LINE 

As printed: 

1 PRIOR LINE 

2 THIS IS AN EXAMPLE OF A LONG INPUT LIN 

AE A A LONG OUTPUT LINE 
6 NEXT LINE 


C. SDDL SYNTAX DEFINITION LEVELS 

The SDDL syntax definitions are subdivided into five levels. The 
primitive definitions are presented in Level 0. Secondary definitions 
based on the primitive definitions are in level 1. Level 2 contains 
SDDL statement definitions. The SDDL control directives are defined 
in level 3. Finally, an overview diagram of an SDDL program, based 
on definitions in levels 2 and 3, is given in level 4. The definitions 
in levels 1 through 4 are accompanied by flow diagrams which specify 
the requirements and options of the syntax. To interpret the diagram, 
trace the flow line from the term being defined to the end of the definition. 
Boxes which are unavoidable are requirements, boxes which can be bypassed 
are options, and boxes which can be returned to are repeatables. The 
contents of a box may refer to another definition or a literal. To 
differentiate between them, definitions appear in smaller type, with 
the definition number in the lower right-hand corner, and literals, 
in larger type, have no accompanying number. 


1. Primitive Definitions (Level 0) 

The following description and discussion of SDDL is based on the 
short list of primitive definitions shown in Table 2. Note especially 
that the definition of a letter includes the pound sign in addition 
to the alphabet. Also note that initially no MARK characters are 
defined. As will be explained later i:\ the discussion of the #MARK 
directive, any punctuation may be converted to a MARK by user specification. 
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Table 2-1. SDDL Primitive Definitions 


Definition 

Number 

Name 

Descripti' , 

0.1 

character set 

The entire set of allowable characters 
(including the blank). 

0.2 

letter 

The alphabet (A-Z) and the pound sign (#). 

0.3 

digit 

The digits (0-9). 

0.4 

punctuation 

The characters remaining after letter, 
digit, and the blank have been deleted from 
the entire character set. 

0.5 

mark 

Any punctuation which has been converted 
by a control directive. (Initially, this 
is the empty set . ) 

0.6 

e.o.s. 

The end of an input statement or directive, 
determined by the end-of-line/record 
indicator (e.g., carriage return) of an 
input line without a continuation mark. 


2. Secondary Definitions (Level 1) 


The definitions of identifier, number, and word shown below are 
based on the SDDL primitive definitions shown in Tab^e 2, 


l.i iDENTIFIER 






1.2 NUMBER 





Note that a number may not have a decimal point. This constraint 
only affects SDDL control directives and has no impact on the design 
statements which appear in the SDD. 


1.3 WORD 



As shown above, a word can be an identifier, a number, or punctuation; 
in short, any token or object definable under the preceding definitions 
of the language. As in natural languages, the space or blank is a 
very important part of the syntax which is needed for delimiting or 
separating words. 
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Example : 

ABC 123 X Y#Z?E 12 4W 

Lexical analysis of the above line yields the following words: 


ABC 123 

(identifier) 

X 

(identifier) 

y#z 

(identifier) 

? 

(punctuation) 

E 

(identifier) 

12 

( number ) 

4 

(number) 

w 

(identifier) 


If ? had previously been converted 
the following words: 

ABC 123 (identifier) 

X (identifier) 

y#Z?E (identifier) 

12 (number) 

4 (number) 

W (identifier) 


to a mark, the result would yield 


1.4 STATEMENT 





A statement, as shown in the diagram above, consists of a sequence 
(including the null case) of words. 

1.5 KEYWORD 


ihe SDDL processor is keyword-driven. A keyword is an indentifier 
which has been predefined to be the name of a structure part (initiator, 
terminator, escape, substructure), a Module Invocation word, or a 
control directive. Keywords are recognized only in context, i.e. 
only when they appear as the first word, though not necessarily starting 
in the first column, of the statement or directive. 

The primary function (in the sense that it precedes and supports 
everything else) of the processor is to reproduce the input statements 
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on the SDD output file in a manner which enhances the reader's capabililty 
to understand the resulting document with the least effort. This is 
accomplished by indentation of statements within structures, and 
superimposition of flow lines to highlight structure escapes and module 
invocations. The actions taken by the processor in response to specific 
statement types are described below. 

1.6 PASSIVE STATEHEMT 


A Passive statement is any statement which does not begin with 
a keyword. Passive statements may be used to convey any design information 
as desired but they do not have any special meaning to the processor 
as do the Keyword statements. 

Passive statements are processed as follows: 

( 1 ) Since Passive statements must be imbedded within a module 
structure, if one does not already exist, the processor 
supplies a module, with an error message. 

(2) The entire statement is scanned for the appearance of any 
identifiers which have been designated for inclusion in 
the cross reference tables. The means for designating 
identifiers for inclusion in the cross reference tables 
is explained under the discussion of the #MARK and the 
#STRING directives. 

(3) The input line number (i.e., the number corresponding to 
the statement's sequential location in the input medium) 
is written at the left margin. 

(4) The entire statement including all blanks is copied to 
the SDD output file beginning at the current point of 
Indentation . 

(5) If the statement contains a pound sign, the portion 

of the statement which follows will all be right shifted 
so that the last non-blank character lines up at the right 
margin. The pound sign itself is replaced with a space. 

This feature has many important applications which are 
examined under the discussion of the #MARK directive . 
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Example: 

As input (input lines 1) ; 
ADD 1 # COUNT CASES 


As output: 


LINE 

PROGRAM STATEMENT SUPPLIED BY 
1 ADD 1 


PAGE 1 
PROCESSOR 

COUNT CASES 


3. Keyword Statement Definitions (Level 2) 

This section describes the Keyword statements which drive the 
processor formatting actions. The actions are summarized in 
Figure 1. 


2.1 MODULE INITIATOR 



Example : 

PROGRAM TO READ THE PROGRAM INPUT 

(1) The keyword PROGRAM is recognized as a Module Initiator. 

(2) The optional noise word TO (FOR or punctuation are 
alternative noise words) is ignored. 

(3) The next identifier, READ, is established as the module 

name and recorded for future cross referencing. The remaining 
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words, including the second appearance of PROGRAM, are 
all passive (i.e., they are handled as though they were 
part of a Passive statement). 

(4) Since a module is the highest-level structure and may not 
be nested within other structures, the processor terminates 
any open structures (i.e., structures which have been initiated 
but left unterminated) with appropriate error messages. 

(5) The entire Module Initiator statement is entered into the 
SDD table of contents. 

(6) The module structure is entered into a push-down (last- 

in, first-out) structure stack for later matching with subsequent 
statements specifying other parts of the structure. 

(7) A new page of the SDD is started with appropriate heading. 

(8) The indentation point is set to level zero (just to the 
right of the location of the input line number field). 

(9) The statement is written to the SDD output file in the 
manner described above for Passive Statements. 

(10) The indentation is increased one level by moving the 
indentation point the required number (default = 3) of spaces 
to the right. 


2,2 BLXK INITIATOR 



Example: 

LOOP UNTIL FILES A, B & C HAVE BEEN READ 

(1) The keyword LOOP is recognized as a Block Initiator keyword. 
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(2) Since blocks must be nested within modules, if an open 
module does not already exist, the processor supplies a 
module with an error message. 

(3) The block structure is placed on the structure stack, as 
described above in step 6 of the Module Initiator statement. 

(4) The statement is written to the SDD output file, as described 
above for Passive statements. 

(5) Indentation is increased one level (see step 10 for the 
Module Initiator statement). 


2.3 TL;:;:1INAT0R 



Example : 

ENDPROGRAM TO READ INPUT 

(1) The identifier ENDPROGRAM is recognized as a Terminator 
keyword . 

(2) The structure stack is searched for a matching Structure 
Initiator. If none is found, the statement is processed as a 
Passive statement and is followed by an error message. No 
further action is taken. 

(3) If a matching structure is found, all Intervening open 
structures are terminated with error messages; 

(4) The structure to be terminated is removed from the top of the 
structure stack; 

(5) Indentation is decreased one level (shifted left) to match 
the indentation of the Structure Initiator statement. 

(6) The statement is written to the SDD output file in the 
manner of a Passive statement. 
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2.4 SUBSTRUCTURE 



Example: 

ELSE TRY ANOTHER ALTERNATIVE 

(1) The identifier ELSE is recognized as a Substructure keyword. 

(2) The structure stack is searched for a matching Structure 
Initiator. If none is found, the statement is processed as a 
Passive statement and followed with an error message. No 
further action is taken. 

(3) If a matching structure is found, all intervening, open 
structures are terminated with error messages. 

(4) Indentation is decreased one level (shifted left) to match 
the indentation of the Structure Initiator statement. 

(5) The statement is written like a Passive statement. 

Indentation is increased one level (shifted right), as 
when the structure had just been initiated, in effect re- 
initiating the structure. 
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2.5 ESCAPE 



Example: 

EXITLOOP IF DELTA < EPSILON 

(1) The identifier EXITLOOP is recognized as an Escape keyword. 

(2) The statement is written to the SDD in the manner described 
for the Passive statement. 

(3) The structure stack is searched for a matching Structure 
Initiator. If none is found, an error message is added 
to the SDD output file. 

(4) If a matching structure is found, the escape statement 
is completed by the addition of a flow line (left arrow) 
extending from the current indentation level to the 
indentation level of the Structure Initiator statement. 


2.6 NODULE INVOCATION 





I 
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Example : 

CALL : INITIALIZATION ROUTINE 

(1} The identifier CALL is recognized as a Module Invocation 
keyword . 

(2) The optional punctuation, is Ignored. 

(3) The identifier INITIALIZATION is established as the name 
of the module to be invoked and recorded for module cross 
referencing. 

(4) The statement is written to the SDD in the manner described 
for a Passive statement. 

(3) The output line is augmented by a flow line (right arrow) 
extending from the rightmost non-blank character of the 
statement to within five columns of the right-hand margin. 

(6) The last five columns of the output line are filled in 
with parentheses enclosing the page number of the module 
referenced by the Module Invocation statement. 

The processor actions for SDDL statements described above are 
summarized in Figure 1. The following example illustrates the statements 
as they might be combined In a simple design: 
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Example : 

As Input: 


1 

2 

3 

4 

5 
4 

7 

8 
9 

10 

11 

12 

13 

14 

15 
14 

17 

18 

19 

20 
21 
22 

23 

24 

25 
24 

27 

28 

29 

30 


prograh to sohnarize Data 
CALL initialize 

loop until all numbers have been read 
READ A VALUE 
call errorcheck 

if the cRRoRCHeCK indicates an e>^ROR 
PRINT the following MESSAGE 
•SOMETHING'S wrong* 

cycle Back for another iteration 
else 

SUM values 4 squared Values 
increment counter 

ENOIF 

repeat 

display Mean and standard deviation 
ENDpROGrAM 

procedure to initialize 
variable 

SUM 

sum oE squares 
COUNT 

LOWER bound 
UPRER bound 

procedure for ERRORCHECK 
initialize ERRORCHECK TO 
IF LOWER Bound < value 
IF value < UPPER BOUND 
reset ERRORCHECK TO INDICATE NO ErROR 
EXItLOOP 
ENOlOOP 


initial value 

0.0 SREAL 
0«0 SREAL 

0 winteger 

0 WREAL 
100«0 SREAL 


indicate an error 
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As output: 


pace line 
NUMBER number 


♦♦♦♦♦♦♦♦♦♦♦♦♦ 


Table or 

♦♦♦♦♦♦♦♦♦♦♦♦ 


module name 


contents 

♦♦♦♦♦♦♦♦♦♦♦♦ 


pace 

♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ 


I 

♦ ♦ 


I program to summarize data 

17 procedure to initialize 

2N procedure for errorchecr 

Module reference tree 

module - CROSS reference listing 


LINE 

1 

2 
3 
H 
5 
A 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 


Data 


have Been read 


program To summarize 
call initialize— 

LOOP UNtIL all numbers 
READ A value 
CALL ERRORCMECk«,«..,.._,.„^.^^__^_ 

*H0ICATES aN ERROR 

Print the Following message 
^•SOMETHING'S wrongs 

^""else^^**^ another iteration 

Sum values g squared values 
Increment counter 

ENOlr 

repeat 

OISPLAT Mean and standard OEVUrlnN 
ENOPROGRAM WE»IATJ0N 


page 1 

•— X 21 


•>C 3* 


line 

17 procedure to initialize 
variable 

1 9 SUM 

zo SUM oF SQUARES 

21 COUNT 

22 lower Bound 

22 UPPER Bound 

ENOPROCEOUrE . STMT SUPPLIED 


initial value 

OtO 


0.0 


0 

0 

100,0 


BY Processor 


page 2 


REAL 

real 

Integer 

real 

real 
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line ^ 

24 procedure for ePRORCHECK 

25 initialize eNPORCHeCK to indicate an error 
24 IP loner Bound < value 

27 IP Value < upper bound 

28 ReHt ERRORCHcCK to INDICaTc no error 

29 ExITloOP 

••••• ••• error ••• INCORRECT HOOuLE ESCAPE NORO 

30 ENDLOOP 

••••• ••• error ••• INCORRECT NOOuLE TERNINATOR 

ENDIF • STMT SUPPLIED BY PROCESSOR 
ENOlF • STMT supplied BY PROCESSOR 
ENOPROCEOUrE • STMT SUPPLIED BY PrqCeSSOR 


••••••••••«•*• MODULE reference TReE •••«•• PAGE 

LN PAGE 

1 1 summarize 

2 2 • Initialize 

3 3 « ErRORCMECK 


module 

CROSS reference listing page 5 


ERRORCMECK 

page 

LINES 

page 

LINES 

initialize 
PAGE 
LINES 
PAGE 
LINES 
PAGE ‘ 
LINES 
SUMMARIZE 
PAGE 
LINES 


I progran to summarize 

Si 4 

% Procedure por eRroRCheck 
24, 2S, 28 

1 program to summarize 
2 

2 procedure To initialize 

17 

3 procedure Por errorcmeck 

2S 

I program to summarize 
I 
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4. Control Directives (Level 3) 

Control directives allow the user to set processor control 
specifications (e.g., page width, Indentation) and to cause some Immediate 
actions to be taken (e.g.» page eject). Control directives are read, 
Interpreted, and acted upon by the processor. They are not written 
to the SDD output file and hence are not seen In the final document. 
Control specifications set by directives are put Into effect as soon 
as they are Interpreted and remain In effect for all subsequent Input, 
or until overridden by another directive. Directives can be used to 
set and reset processor control specifications as often as desired. 

The SDDL control directives are defined and deucrlbed on the following 
pages. The sequence of presentation Is Intended to avoid lookahead 
caused by definitions based on terms defined on subsequent pages. 

Control directive keywords all begin with the pound sign character. 
They are preset (see Table 2) and must not be altered. The user must be 
careful not to define a new meaning for a control directive keyword 
(see #DEFINE directive) since It will cause the preset definition 
to be overridden. 


0.1 HARK DIRECTIVE 



Selection of words or Identifiers for cross referencing Is 
controlled by the IMARK and the iSTRING directives. When using the 
#MARK directive, the designer specifies a list of punctuation which 
the processor subsequently treat In the following manner: 

(1) Ai> ' '.ctuatlon appearing In the statement Is converted 

Into a MARK (syntax definition 0.5), l.e., those characters 
which are used to form Identifiers. They can then be used 
as connectors to build a single Identifier out of separate 
words. 
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Example : 


#MARK . 

EVERY .GOOD .BOY DOES FINE 

(2) Every identifier which includes a MARK, such as in 
EVERY .GOOD .BOY in the example above, is included in 
a cross reference listing produceu at the end of the 
design document. 


Titles for the cross reference listings may be supplied by placing 
any string of characters (except punctuation) prior to the punctuation 
to be converted. If no title is supplied prior to the first punctuation 
Jji the directive, a blank title is assumed. 

The SDDL processor provides individual cross reference listings 
for each unique title found in the #MARK and/or ISTRING directives. 
Identifiers containing MARKs which were specified with identical titles 
are merged into a single cross reference listing. Titles are considered 
to be identical if, after deleting leading and following blanks, they 
are an exact, character-by-character match, including internal (between 
word) blanks. Identifiers which contain marks associated with several 
unique titles will appear in each appropriate cross reference. These 
conventions are exemplified below, and an additional, more comprehensive 
example is given following the #STRING directive. 

Example: 

#MARK ?! DATA ITEMS % REVISIONS $ 

#MARK ; DATA ITEMS .: 

The MARKS specified in the above example are associated with the titles 
as follows: 


CROSS REFERENCE LISTING 
? I ; 


DATA ITEMS 

CROSS REFERENCE LISTING 

} . : 

REVISIONS 

CROSS REFERENCE LISTING 

$ 
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3.2 STRING DIRECTIVE 



\ 


This directive allows the user to specify one or more punctuation 
marks to be used as string delimiters. The purpose of enclosing text 
within string delimiters is to have it included in a cross reference 
table at the end of the document. The following rules govern the use of 
this feature. 

(1) Several MARKs may be specified as string delimiters but no 
distinction is made between left (opening) or right (closing) 
delimiters 

Example: 

#STRING () 

1 SAMPLE STATEMENT (STRING 0NE( 

2 ) STRING TWO (NOT A STRING) STRING ABC) 

In the above example, the following text segments are defined and 
will be cross referenced: 

"STRING ONE" "STRING TWO" "STRING ABC" 

(2) Preceding and following blanks are excluded from the string, 
but interior blanks are indluded. 

Example : 

♦STRING ' 

LINE 1 ' ABC D' 

LINE 2 'ABC D ' 

LINE 3 'ABC D* 

The strings in LINE 1 and LINE 2 are the same because they match 
exactly after preceding and following blanks are stripped off. 
The string in LINE 3 does not match the others because it 
does not have the same number of spaces between ABC and D. 

Each unique string, where uniqueness is defined by rules 
1 and 2, becomes a single entry in the cross reference. 
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(3) If the closing delimiter is omitted, the string is terminated 
by the end of the input statement. 

Example : 

♦STRING * 

LINE 1 'ABC AND 'DEF G 
Strings ABC and DEF G are recognized. 

(4) If the text enclosed in string delimiters consists of a 
single identifier, regardless of preceding or 

blanks, it is recognized as described above, but in addition, 
the processor will thereafter recognize and cross reference 
the named identifier whether it appears with or without 
delimiters. 

Example : 

♦STRING ” 

LINE 1 "VEHICLE " 

line 2 VEHICLE AND VEHICLE 

In the above example, VEHICLE is recognized and the cross 
reference will show that it was found once in LINE 1 and 
twice in LINE 2. 

(5) A title for the cross referencing of text strings may be 
supplied by including any characters except punctuation 
between the ♦STRING keyword and the first MARK to be 
converted to a string delimiter. 


The title (including the null case) supplied with ^he JSTRING 
directive is compared with the titles supplied with the ♦I^RK directives 
for merging of the cross reference listings. When several ♦STRING 
or ♦MARK directives with conflicting title specifications are used, 
the rule followed is that the last usage overrides all prior usage. 
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Example : 

As Input: 


REVISIONS t 


nsHARK ?t oata items * 

2;«maric data items .t 

JjPROGRAM TO^REAO^OaTA ANO •CHECK" IT 

sireao Vehicle: • max*rpn , spower • 

aiif any values are unknown? or untested? 

7ICHECK THE DATAII FON OOUBTFUL*STuFF? *1 

b:enoif ^ ^ 

?:an additional check hay be needed here 

IOIENOpROGrAM 


"and what ever else there is 


As output: 


Table of contents page i 

PAGE line *^^**^^********^***^*************^**^*******^**'^^****^*** 
NUMBER number MODULE NAME 

1 M PROGRAM to R£AD DATA AND "cHECK" IT 

2 MODULE reference TREE 

3 MODULE - CROSS REFERENCE LISTING 

^ data items - CROSS reference listing 

s revisions • CROSS reference listing 

4 CROSS reference listing 


line 

H 

5 

A 

7 

a 

? 

10 


page I 


program To read data and "check" it 
Read vehicle: • max.rpm , ipower 


"and what ever else the 


frRE Is ** 

IF any values are unknown? OR untested? 
check the DATAji f’OR DOUBTFUL, STUFF? »l 

an^additIonal check may Be needed here 

ENDPROGRAM 
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DATA ITEMS 

CROSS reference listing RAOE m 

1 DENT IFIER^ ♦♦♦♦♦♦♦♦♦♦*♦♦**♦ ♦^^♦****^^***^^^**^***^***^*^^^****^^^*** 


SPOWER 


PAGE 

1 

Program 

TO 

read 

LINES 

5 




AND WHAT ever 

ELSE there 

IS 

PAGE 

1 

Program 

TO 

read 

LINES 

S 




CHECK 





PAGE 

1 

program 

TO 

read 

LINES 

M 

* 7i 9 



DOUBTFUL*STUPP? 



PAGE 

1 

Program 

TO 

READ 

LINES 

7 




NAX.RPM 





PAGE 

1 

program 

TO 

read 

LINES 

S 




vehicle: 





PAGE 

1 

program 

TO 

read 

LINES 

s 





REVISIONS 

CROSS REFERENCE LIStING PAGE 6 


PAGE I program TO REaD 
lines 7 


CROSS reference listing page 6 

lOENTIFlER^^^^^^*******^*************^^***^^***********^^****^******* 

OATAI I 

PAGE I PROGRAM TO READ 

LINES 7 
OOUBTFULtSTuFP? 

PAGE 1 program TO read 

lines 7 
unknown? 

PAGE I program to read 

LINES A 
untested? 

PAGE I program to KEAO 

LINES 6 
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The #DEFINE directive ia used to specify new or to delete old SDDL 
keywords. To select the desired action, one of the four words shown below 
must follow the SDDL keyword, #DEF1NE. 

MODULE BLOCK CALL NULL 



The word MODULE or BLOCK is used to define a control structure. In 
SDDL, a control structure has four parts; 

(1) Initiator: Increases the indentation level for subsequent 

lines . 

(2) Terminator; Closes all nested structures left open anti 

returns the indentation level to that of the 
Initiator statement. 

(3) Escape: A left arrow is added to the statement to 

indicate the program control flow. The arrow 
extends from the indentation level of the 
escape statement to the indentation level of 
the Initiator statement. 


(4) Substructure: Closes all nested structures left open, returns 

the indentation level to that of the Initiator 
statement, prints the line, and increases the 
indentation level. 


When defining a module or block, names for the four parts must be 
specified in the order shown above. Any punctuation may be used to 
separate the part names, but care must be taken to avoid using a MARK 
(i.e., punctuation which has been converted to a MARK by the #MARK 
directive). Names for any of the parts except the initiator may be 
omitted by using consecutive punctuation to show where a name has been 
left out. Any text following the name of the substructure will be 
ignored. Synonyms for part names, except for the initiator name, may be 
established by additional #DEFINE directives. 
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Indentation apeelfic to the named "truoture my 
the current default indentation amount (see #INDENT) will 


Example (three equivalent directives): 


tYi^ 

module 


♦DEFINE MODULE 10 PROGRAM, END, STOP, ENTRYPOINT 
♦DEFINE MODULE 10 PROGRAM END , STOP ENTRYPOINT 
♦DEFINE MODULE 10 PROGRAM END STOP ENTRYPOINT WHATEVER 


Indentation 

10 


Initiator terminator fi flca fts aubstructuT A 

PBOGRAM end STOP ENIRIPOINT 


Example : 

♦DEFINE BLOCK BEGIN END 

t..oe indentation inltjateii UrB l n a ta c sasans 

blook default BEGIN END 


ppihetpucture 


Example : 


iSSiS. 


block 


♦DEFINE BLOCK START, FINISH, LEAVE 
♦DEFINE BLOCK START, , SCRAM 
♦DEFINE BLOCK 2 START, , VAMOOSE 

Indentation Initiator. Ura l nato n sssaas. aubatruot urfi. 

LEAVE 

? START FINISH SCRAM 

^ VAMOOSE 


on the previous directives. 
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The word CALL is used with the #DEFINE directive to establish 
synonyms for the Module Invocation keyword (default keywords are CALL 
and DC), which indicates that a module is to be invoked at the point 
where the statement occurs. The identifiers to be defined as synonyms 
are listed after the word CALL. Punctuation for separating the words 
is optional. 

Example: 

#DEFINE CALL PERFORM EXECUTE, GOGOGO 

#DEFINE CALL DOITNOW 

Example : 

#MARK . 

#DEFINE CALL DO. IT. NOW, PERFORM 

The identifier DO. IT. NOW (also PERFORM) becomes a Module 
Invocation keyword because the period has been converted to a MARK 
by the prior #MARK directive. Where DO. IT. NOW appears in the context 
of a keyword (first word of the statement), it will not be included 
in the cross reference table. 

When a Module Invocation statement is encountered, the processor 
places the statement in the output file with the appropriate indentation 
and adds a right arrow from the rightmost character in the line to ’ 

the right margin. Matching parentheses are added to the right of the 
arrow to provide a place for adding the page number of the called module. 

If the module that is referenced in the Module Invocation statement | 

has been defined on a prior page, the page number is supplied in the I 

allocated space when the statement is encountered. Page reference 
numbers which cannot be supplied immediately must be filled in on a ^ 

second pass over the output file. The user may exercise the P option | 

at execution time to suppress the second pass, which supplies the remaining ! 

page reference numbers. = 

i 

I 
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The NULL action of this directive provides a means for returning 
any previously defined keywords to the state of being undefined. 
Punctuation may be used as a keyword separator, if desired. MARKs 
which have been converted to letters by a previous #MARK or #STRING 
directive may also be listed for redefinition as punctuation. MARKs 
eing redefined in this manner must have adjacent blanks or punctuation 
to disassociate them from other text. 

Example : 


#DEFINE NULL PROGRAM, ENDPROGRAM PROCEDURE 

The words PROGRAM, ENDPROGRAM, and PROCEDURE are not recognized 
as keywords in the statements following this directive. 

Example : 


#MARK .$ 

#DEF1NE NULL DO. IT. NOW $ 

The word DO. IT. NOW is no longer a keyword and $ reverts 
to punctuation again. The periods in the keyword DO. IT. NOW are part 
of the identifier (unlike the $ in the example), and therefore the status 
of the period remains unchanged; i.e., it is still a MARK. 

Example; 


#MARK . 

#DEFINE NULL . DO. IT. NOW 

This example differs in that the status of the period is reconverted 
to punctuation first and is treated as such in the remainder of the 
statement. Therefore, DO, IT, and NOW are the words which become undefined. 
If DO, IT, and NOW are already undefined, they are not affected. 
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This directive is a generalized terminator for block structures 
It may be used in place of a number of specific terminators (specific' 
terminators must match their respective initiators) to terminate the 

®<^*''^ctures. If no integer is specified 
in the directive, only one structure will be terminated. If n is greater 
number of open block structures, they will all be terminated, 
out the module structure will not be affected. 

Example : 


As input: 


1:PR0qRAm ’•terminate" example 
2:IF P indent i level 

3JL00P Q indent 1 LEVeL 

m: indentation is 3 levels deep 
SIENOlOOP - SPECIFIC termjnator 
6IENDIF . specific TERMINATOR 

7JIF p indent 1 level 
8JLOOP Q indent 1 LEVEL 

9; indentation is 3 levels Deep 


io:*termin4Te lOo 

^e«""-*Teo . hooul£ not .frECreo 

13IL00P Q indent 1 LEVEL 

m: indentation is 3 levels deep 
1S:*TERMINaTE only one structure terminated 
lAIIF P indent 1 level 
171 indentation is still 3 levels deep 

ISiENOPROSHAM . STRUCTURES LEFT OPEN ARE TERMINATED 


BY the processor 
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As output: 


INE 

1 prograh "terminate" example 

2 IF P indent I level 

3 LOOP Q indent I level 
Indentation is 3 levels deep 

ENOLoOP - SPECIFIC TERMINATOR 
ENDlF - specific TERMINATOR 

7 IF P indent I level 

8 LOOP Q indent I level 

9 Indentation is 3 levels deep 

11 ALL BLOCK STRUCTURES Are TERMINaTeD - MODULE NOT AFFECTED 

12 IF P indent I level 

13 LOOP Q indent I level 

m Indentation is 3 levels deep 

16 IF P indent 1 LEVEL 

17 indentation is Still 3 levels deep 
endif - stmt Supplied by processor 

ENOlF - STMT supplied BY PROCESSOR 
19 ENOPROGRAM - structures left OPEN aRe TERMINATED BY THE PROCESS 

BOR 


3,5 TEXT DiRECTiVt 



Examples : 

#TEXT 

#TEXT COMMENTARY BEGINS ON NEXT LINE 


The #TEXT directive is used to signal the beginning of a sequence 
of lines (not statements) of text intended as commentary to the SDD . 

When this directive is encountered, the processor performs the following 
actions : 

(1) The words following the keyword are ignored. 

(2) The processor begins reading input lines into a holding 
buffer and continues until it encounters an input line 
whose first non-blank character is the pound sign. 

(3) The lines buffered in step 2 (this does not include the 
line which terminated step 2) are not analyzed as statements 
but simply saved unaltered. 
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(4) The buffered lines, enclosed in a box formed by asterisks, 
are then written to the SDD output file at the current 
level of indentation. 

(5) The line which signaled the end of step 2 (the buffering 
step) is then processed in the usual way. Thus, any control 
directives or any statement which begins with a pound sign 
may be used as a terminator and still be recognized for 
regular processing. If no action other than termination 

of the text statement is desired, the #END directive may 
be used. 


3,6 END DIRECTIVE 



This directive has no effect other than that of terminating 
buffering for #TEXT and #TITLE directives. 


line 


3,7 TITLE DIRECTIVE 



Example : 

#TITLE SDDL DESIGN DOCUMENT 

itTTTr directive is used to produce a title page in the SDD. The 

#TITLE directive is similar to the #TEXT directive, but different in 
directive resembles a Block Initiator statement while 
the #TITLE directive resembles a Module Initiator statement. The 

performs the following actions in response to input of a 
ffTITLE directive. 

( ^ ) The keyword #TITLE is recognized . 

(2) The initial pound sign is stripped off, and the remainder 
of the directive is entered into the SDD Table of Contents. 
Title line entries in the Table of Contents are preceded 
by a blank line and are written two columns to the left 
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of module entries in order to distinguish them as the 
beginning of a document section. 

(3) All structures left open are terminated with error messages. 

(4) As in the case of a #TEXT directive, the processor reads 
and buffers input lines until it encounters a line whose 
first non-blank character is a pound sign. Termination 
of the title text is the same as for the #TEXT directive. 

(5) A new page is started in the SDD output file. 

(6) A title page is formed by (a) enclosing the lines in a 
box formed by asterisks, (b) centering each line within 
the box, and (c) centering the entire box on the page. 


3.8 UNENUM3ER DIRECTIVE 



This directive provides control of the starting point of the 
input line numbering sequence which the processor produces in the left 
margin of the SDD . 

The input line numbers supplied by the SDDL processor correspond 
exactly to the positional line numbers of the data element (card deck) 
of the input to the SDDL processor. This feature obviates the listing 
of the raw input for revising and augmenting the SDD. Where more than 
one element (deck) is used as input to SDDL, it is desirable to reset 
the line counter so that numbering can be made to match the subsequent 
elements (card decks.) 

If this instruction is issued without an accompanying integer, the 
processor will begin numbering subsequent lines from 1; otherwise it will 
begin numbering with the value specified by the integer. The syntax of 
this directive allows noise to be used for commentary if desired. 

Examples : 

(/LINENUMBER 1001 STARTS THE NEXT ELEMENT 
#LINENUMBER 
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The SDDL ^INDENT directive allows the user to override the default 
value for the number of spaces to be skipped for automatic statement 

indentation . 

User-defined structures (see #DEFINE directive 3-3) which 
do not have a specific indentation amount declared and SDDL initial 
s^rucJu^rdefinUlons always use the current default indentation value. 
The initial value of the system defined default indentation amount 
is three spaces. 


Text following the integer (i.e., 
if desired. If no integer is specified 
value of three spaces is assumed. 


noise) may be used for commentary 
in the directive, the default 


Examples: 

#INDENT 5 SPACES UNLESS OTHERWISE SPEClflED 
^INDENT SET TO DEFAULT OF THREE SPACES 



The #WIDTH directive provides user control of the width of the 
output pages. The default page width is 80 characters = 20 cm (b in.). 

An integer specifying the width, in characters/output line 
should be supplied. If the integer value is not in the range 60- 3 , 

an error message will be printed and value%f SO 

If no integer is specified in the directive, the default value of 

columns is assumed. 

This directive may be used as many times as desired throughout 
the program. Each use affects only the output which follows it. 
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Example : 


#WIDTH 130 COLUMNS FOR A TABLE 


i<WIDTH RESUME NORMAL PAGE WIDTH 



This directive provides immediate control of the start of a 
new page in the SDD . This page control is over and above the automatic 
new page start caused by (1) a title, (2) the beginning of a njw 

an ovLflow ^ becomes lengthy enough to cause 

an overflow to a new page, it is often desirable to control the start 

page bounLJy"' ^ ^ 

new "" accompanying integer, causes a 

inpurstreL^ started beginning with the next 3DDL statement in the 

Examples : 

#EJECT 

#EJECT A PAGE NO MATTER WHAT 

fn ho integer is included in this command, it causes a new page 

the Lmber n? V ^ remainder of the page cannot accommodate 

the number of lines specified by the value of the integer. An integer 

di>ectfve"t'"h''"" — the 

martherefnrp h f'°iiowing the integer is ignored and 

may therefore be used for commentary. 


Examples : 


REJECT 5 

//EJECT 7 THE FOLLOWING 7 LINES MUST BE KEPT TOGETHER 
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3.12 SEQUENCE DIRECTIVE 



The #SEQUENCE directive is provided for card input to the SDDL 
processor . When SDDL is used in a timesharing environment with file 
management and editing capabilities, card sequencing is unnecessary. 

In this case, the full 80 columns of the input line may be used entirely 
for SDDL statements and directives and the #SEQUENCE directive can 
be ignored, except to avoid its inadvertent use. The input line numbers 
supplied in the left margin of the output file correspond exactly to 
the line to edit the input file for corrections and updates and may 
be reliably used for this purpose. This feature makes it unnecessary 
to print out copies of the raw input file. 

Where cards are used as the input medium, it may be desirable to 
have card sequence numbers at the right-hand edge of the card, in which 
case the #SEQUENCE directive must be used to differentic-te between the 
input text and the sequence numbers. As shown in the cyntax diagram 
above, the #SEQUENCE keyword may be followed by an optional integer. 

This integer may be used to specify the number of rightmost columns to be 
considered to contain sequence numbers. If no integer is supplied or a 
value greater than 8 is specified, the default value of eight characters, 
columns 73 through 80, is assumed. An integer value of zero has the 
effect of disabling the card sequence capability. When the ^SEQUENCE 
capability is used, the input line (except for the sequence numbers) is 
handled in the usual way, and the sequence numbers are printed in the 
rightmost columns of the output page as determined by the #WIDTH directive 
(default = 80 columns). Where an input line is continued over more than 
one card, only the sequence number of the last card is printed. 

Example : 

#SEQUENCE 4 

Columns 1 through 76 of the input deck are assumed to contain 
SDDL statements uifuctives, and columns 77 through 80 are assumed to 
contain sequence numbers. 
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5. SDDL Syntax Overview Diagrams (Lev el Jil 


4.0 SDDL PROGRAM 



4.1 TITLE GROUP 
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4.3 STATEMENT GROUP 



4.4 TEXT GROUP 



4.5 BLOCK 
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4.6 OMROL DIRECTIVE 
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SECTION III 
SAMPLE DESIGN 


Two examples are presented to illustrate the capability and potential 
of the SDDL processor. The design of the SDDL processor itself is 
the subject of the first example. Only a small subset of the actual 
SDDL design is shown in order to reduce the example size to expedient 
proportions. Even this small, top-level portion of the SDDL processor 
design, however, reveals information which has an important impact 
on the processor. 

The second example demonstrates some of the actions taken by 
the processor in response to error situations. The subject material 
is not intended to convey any meaningful design information. 

Example 1. Top-level SDD for the SDDL processor: 

As input: 


1 

2 

3 

4 

5 
A 

7 

8 
9 

10 
1 1 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 


•mark revisions * program portability considerations ? 

• HARK ROUTINES aNj) FUNCTIONS - DAyA ITEMS 

•string Data items - 
•define block '2 list 
•define slock 2 member 
•define block loop, , , Begin 
■title sOOl example 

SOpTwARE OeSIgN ANO DOCUMENTATION LANqUAGE 

(AN illustration qP THE ApplICATIqN qP SODL USING THE) 

(SOOL Processor itselp as the obUeCt of the example* i 
■end 

program objectives 

■TEXT 

the objective op SOOL IS TO pRqVioe an eppective communications 
medium tO support Tmc design and documentation op complex software 
applications. this objective is met by providing; 

(1) A DESIGN And documentation LANGUAGE #<ITH PORMS AND SYNTAX 

that are simple» JnrestriCt I ve I and communicative 

(2) A PROCESSOR wHiCH CAN CONVERT OESIGn SPECIFICATIONS INTO AN 
INTELLIGIBLE, INFORMATIVEi MACHINE REPRODUCIBLE DOCUMENT 

(3) mLTHODJLOGY pOR EFFECTIVE US£ Op ThE LANGUAGE AND PROCESSOR 
■end 

program DATA.iTRUCTUHE aNj GLOSSARY 
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33 

3M 

35 

36 

37 

38 
3 ? 
HO 
HI 
H2 
H3 
H^l 
H5 
H4 
H7 
H8 
H9 

50 

51 

52 

53 
5H 

55 

56 

57 

58 

59 

60 
61 
62 
63 
6H 

65 

66 

67 

68 

69 

70 

71 

72 

73 

79 

75 

76 

77 

78 

79 

80 
81 
82 

83 

89 

85 

86 


input*text. buffer 


TEXT*Len5TH 


list: token, dictionary 
hehber entity: entry 

CHARACTeR«CoWNT 

TEXt«POiNTER 

program;name 


list; reference. list 

HEMBER entity; "REFERENCe** 

PA6C»NunBER 

L1Ne*NUmBER 

•terminate 9 

list; mddule^stack 


A global character array containing 
A single input statement formed by 
concatenation of continued input Lines 

THE length of the CURRENT INPUT LInE 
(TRAILING blanks NOT INCLUDED) 

linked list of dictionary entries 
pointer to a single dictionary entry 
number of characters in the entry 
pointer to the character array 
containing the text of the entry 
IF entry is a keyword this is the 
LOCATION or identification OF THE 
routine for processing THE STMT 
VALUE-0 IF entry IS NOT A KEYWORD 
first-in, FIRST-OUT LIST oF 
references to the entry 


member entity; node 

NOOEfNAME 

indentation, Column 
•terminate 2 

enoprogram data. structure 

PROGRAM MAIN ROUTINE 

CALL initialization routine 

LOOP until all input Data has been processed 

CALL set-statement » «l 

•yield TEXt.LENGTH 


PUSH DOWN stack oF NqOES REPRESENTING 
THE NESTED STRUCTURES OF THE DESIgn 


THE NESTED STRUCTURES 

I if, loop, program, ETC) 


call Token. finder 

•yield tOKEN*TYPE 


(FINDS THE first TOKEN IN THE STATEMENT) 


IF TOKeN.TyPE IS "identifier" 

call ENtABle to find the token in th^ token, dictionary 

ENDlF 

IF the token was found and it is a KEYWoPD 
CALL Keyword, processor 

else the Statement does not begin With a keyword 

IF the liOOULEtSTACK IS EMPTY 

push a program module on the module, stack 

ENOIF 

call Source, lister to send the statement to the output file 

ENDlF 

flush any "error messages" triggered by the statement 
repeat 
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87:CALL WRaP-UP 
bsiexitprogRah 

89 {ENDpROGRAM 

9o:procedure; get.statehent » ii 
9i;»USlNG iNPUTfTEXT, buffer 
92!*7lEL0 TEXTtLENGTH 


record is pound 

NOT ENPTY (A MODULE EXISTS) 

NUMBER and A BLANX LI^E TO THE *SOO« 


« 777 


93 ; 

9R5READ an INPUT RECORD 
95JL00P UNtIL a N0N»BLANK 
96IIF THE module. STACK IS 
97:PRINT the lNf*UT RECORD 
9b:endif 

99;READ another input record 

in»*rnPY THr INPUT RECORD INTO THE I NpUT • TEXT • BUFFER 
102:SET TEXt.LENSTH ■ “uSABUE columns**! 80 - card sequence COLS) 

1o4*find the Last non-blank character in input. text. buffer 

lOSiSET TEXT.LENGTH • COLUMN NUMBER Op THE CHARACTER 
106IIF the character IS NOT A CONT I nUaT X ON *MARK 
107SEXItPR0CEDURE 

I FROH the TEXT-LENGTH IBACX UP OVER THE CONT I NUAT I ON. HARK ) 
llOJlF there Is no '.more data (END OP PILE ENCOUNTERED) 

1 1 1 ;ex I tprocedure 

lia'lF^THE SPACE k-EFT IN I NPUT . TE XT. BuFPER < 80 CHARACTERS » 77? 
iiriexpano input. text.buffer 3y at cEaSt 80 characters '»? 

I ISIENDIF 

115;co?? iH/uiJufRSJ nu^^NPUT. text.buffer beginning at text.length 
IIbIaDO "USa«LE columns" to text. length 

n9;RCPEAT 
120;ENDPR0CeDURE 

1 2 I ‘.procedure For initialization 
122;READ in execution time option 


flags from execution statement 


123 : 

i2r; 

125) 

126) 
127? 
128: 
1 29 ; 

130; 


option. B 
OPTION. c 
OPTION. E 
OPTION. K 
qPTIoH.M 
OPTION, P 
OPTION. R 
OPTION. T 


BREAKPOINT 
CROSS REFERENCE 
"error MESSAGES" 
keywords 

MODULE CROSS REFERENCE 
page reference numbers 
reference tree 

TA0LE OF CONTENTS 


1315 

I32.IF OPTION. 8 IS NOT SET bREAKPOiNTiNG IS REQUIRED 

i33:read in remainder of EXECUTION statement 
) 3 ‘ 4 :if a name is specified fur the 5 O 0 output FILE 
135;SET UP A ausL relationship with SdD 
136:EN0iF , 

137;CATaL0G ano assign sdo as the output file 
138;IF the catalog step failed 

1391PR1NT AN F.RROR MESSAGE 
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IHO: 
i4i : 
i'»2: 
143 ; 
14*»: 


TERHlNATt THE PROCESSOR 

EXiTPROcEfURE 

ENDIF 

breakpoint the output to sod 


145;ESTa8LIsH the POLLOWIN& 

i4a; Characters. per. word 
Buffer, COUNT 
pead.unit 

WRITE, UNIT 

Default. indent 

right. MARGIN 


147; 

146; 

149; 

i5o; 

151 ; 


152; 

INPUT.TExT. buffer TO At LEAST 80 CHARACTERS 
1 59 , ESTaBL 1 sH token. 0 I Ct I ONARY DATA STRUCTURE 

establish default keywords 

15a;EX1TPR0cEDURE 

157;EN0PR0CeDURE 

158;Pr0CEDURE FoR KeYworD.sET UP 
I59;loop using the following Data pairs 

160; (S • POUND SIGN IN KEYWORDS BELOW) 

ui; Keyword procedure name 

1A2; ------- . 

U3; 

149; 


HAtMINE dependent constants 

■ 6 

■ 14 (I9*6«89 CHARS/LINE) 

■ 5 

■ 6 
• 3 

■ 80 


Smark 
^string 
i6s; sinoent 
1661 »LINENUM8ER 
167; itext 

168; *title 

169; *END 
170; *DEF1nE 
I7i; *EJCCT 
172; *WIDth 
173: ^sequence 

179: BtERMiNATE 


Set. DATA, CHAR 
SET.ST'-dNG.CHAR 
SET.I^DENTATION 
set.linenumber 

0OX.tE)'T 

Box. text 
end. CONTROL 

D^i«^lNE.WORDS 
EJECT-PAGE 
SET.PAGE. width 
CArD'seQUENCING 
Blind. terminator 




i7s: 

I76:BeGiN iteration 

iTaisTOor T 0K£ N . D I C T I 0 N A R y 

w’iwoLOoJ nane into prosran.nahe of the entry 

180;EN0PR0Ce0URE 
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I 

j 



r 


« 7?? 
• ??? 
■ 777 
« 777 


« 777 


As output: 


software oesiun and oOCUHENTATION language 

(AN illustration OF THE APPLICATION OF SODL USING THE) 
(SDOL processor ITSELF AS T«E OBJECT OF THE EXAMPLE. ) 


PAGE 

number 


table of contents page I 

line 

number mqoule name 


0 

1 

2 

3 

H 

5 

6 


7 title suol example 
16 program ODJECTIveS 

31 program LATA_5TRUCtURE ANO GLOSSARY 

63 PROGRAM main ROUTINE 

90 procedure: get. statement 

121 procedure for I N I T I AL 1 Z AT 1 oN 

isa procedure for keyword. Set.uP 


7 Module reference tree 

e module - CROSS reference listing 

9 data items - CROSS REFERENCE LISTING 

2 revisions - CROSS REFERENCE LISTING 

3 PRqGRaM portability considerations - CROSS REFERENCE LISTING 

H routines mNU functions - CROSS REFERENCE LISTING 


SI 
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LINE 

U 

17 

18 
18 
20 
21 
22 
21 
2*1 
28 
24 

27 

28 
2f 
30 


PAQC 


PR06RAM Objectives 


objective oF sdol is to PAOVIOe an effective communications 
M rOIUM TO support TN£ OeSI«N ^No DOCUMENTATION OF COMPLEX SOFT ARE 
applications, .this objective Is net BT PROVIOINBj 

(II A OESI«N and documentation LANsUAqE STNTAx 

** THAT ARE SIMPLE# ONRESTRiCT I VE . AND COMMUNICATIVE 

A PROCESSOR WHICH CAN CONVERT OESIfiN SPECIFICATIONS INTO AN 
tN?UU6?!lEriHF0RMATlVE. HacHINE REPRODUCIBLE DOCUMENT 

(1) MeTHODOLOGT for EFFECTIVE USE OF THE LANGUAGE AND PROCESSOR 


ENOPROGRAM - STMT SUPPtlEO BY PROCESSOR 


^^31 program DatA-STRUCTURE ANo GLOSSARY 
32 

INPUTtTEXT.BUFFER 


33 

3H 

35 

36 

37 

38 
3? 
HO 
HI 
H2 
H3 
HM 
H5 
H6 
H7 
H8 
H? 
SO 
St 

52 

53 
S5 

54 

57 

58 
5? 
60 
62 


TEXT*LeNGTH 


list; toi^en, dictionary 
Member entity; entry 
character. count 
text. pointer 


PROGRAM.NaHE 


list: reference. list 
MeHBER entity; "reference" 

PAGE.NUMBeR 

LINE.NUMBER 

list: mooule.stack 

member entity; node 

NOOE.NAME 

indentation, column 
ENOPROGRAM DATA. structure 


PAGE 2 


A global character array containing 

A SINGLE INPUT STATEMENT FORMED BY 

concatenation of continued input lines 

THE length of the CURRENT INPUT LINE 
(TRAILING blanks NOT INCLUOEOJ 

linked list of dictionary entries 

POINTER TO A SINGLE DICTIONARY ENTRY 

number of characters in the entry 
pointer to the character array 
containing the text of the entry 
IF entry is a keyword THIS IS tHE 
location or identification of the 
routine for processing the stmt 

VALUE"0 IF ENTRY IS NOT A KEYWORD 
FIRST-IN, FIRST-OUT LIST OF 
references TO THE ENTRY 


PUSH DOWN STACK OF NflOES REPRESENTING 

the nested structures of the design 

( IF.LOOP, program, ETCI 
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line pace 3 

63 procram Main routine 

6R CALL initialization ROuT I NE-- — — — • — — — &) 

65 LOOP UNtIL AtL INPOr DatA HaS BeEN PROCESSED 

4A CALL CET. statement tIM r) 

67 •TIElO text. length 

66 

69 call TOKEH.flNOER <plNOS THe plRST TOKEN IN tHE STATEMENT ) ——>( ) 

70 •TIELO TOXEN.TYPE 

71 

72 IP TOAEN.TYPE is "IOENTIPIER" 

73 Call ENTABLE to find the token in the token, OICTiONARV——>( i 

7R ENOIf 

75 

76 IP the T0X£N Was pound and it is a KE'^WORO 

77 call KEYHORO.pROceSSOR----------- - — — -X I 

78 else the statement DOES NOT BEGIN WITH A KEYWORD 

79 IP The module. stack is empty 

80 Push a program module on the mooule«stack 


ei endif 

82 call source. lister TO SEND tHE STATEMENT TO THE OUTPUT PILE->< I 

83 ENOIf 
6H 

85 FLUSH ANY "ERROR MESSAGES" TRUGEREO BY THE STATEMENT 

86 REPEAT 

87 CALL Wrap. UP--- ) 

88 <«-EXItPROGRam 

89 CNOPROGRAM 


LINE 

90 PROCEDURE; GET. STATEMENT 
9 ; •USING INPUT. TEXT, buffer 

92 •yield text. length 

93 

99 read an input RECORD 

95 LOOP until a NON-BLANK RECORD IS FOUND 

96 IP the module. stack IS NOT EMPtV (A MODULE EXISTS) 

97 Print the input record number and a blank line TO the "SOD" 

98 ENDIF 

99 READ another INPUT ReCoRD 

100 repeat 

101 COPT the input record into the iNpUT. text. buffer 

102 SET text, length ■ "USABLE COLUMNS"! 80 - CARO SEQUENCE COLSI 777 

103 LOOP 

lOH PINO the last NON-BlANK CHARACTER IN I NPUT. TEXT, BUFFER 

105 SET text. length ■ CoLUHN NUMBER OP THE CHARACTER 

106 IP THE character IS NOT A CONT I NUAT I oN, MARK 

107 < — — — -ExITPROCEOURE 

109 IuBTRACt I from tHE text, length (BACK UP OVER THE CONTINUATION. MArK) 

110 IF THERE IS NO MORE DATA (END OF PILE ENCOUNTERED) 

111 < — — — -EXITPROCEOURE 

112 ENOIF . . 

113 JF the space Left in input. TEXt*BUFFER < *0 characters 7 t 7 

119 EXPAND input, text, BUFFER RY AT LEAST 80 CHARACTERS 7?7 

115 endif 

116 READ IN another INPUT RECORD 

117 COPY the input ReCORO INTO I nPuT, TEXT« flUf PER BEGINNING AT TCXT.LEnGTH 

lie add -usable COLUMNS" TO text, Length 

119 repeat 

120 ENDPROCEOURE 


PAGE R 

Bl 


3-7 


77-24 


LINC 

121 

122 

12:^ 

12«t 

125 

12 * 

127 

128 
128 

130 

131 

132 

133 
138 
135 

134 

137 

138 

139 
180 
191 
182 
143 
188 

185 

186 

187 

188 
189 

150 

151 

152 

153 
158 
155 

154 
157 


^ROccouRc roR initialization 

READ IN execution tINe O^TIoN FLAfiS FROM EXECUTION STATEMENT 


FA6E 


OPTION, B 
OPTION, C 
OPTION. E 
OPTION. K 
oPtioN.m 

OPTION. p 
OPTION, R 

OPTION, T 


BREAKPOINT 
CROSS refemence 
"ERROR MeSSaoeS" 
KEYNOROS 

module Cross reference 
pace reference numbers 
reference tree 
table of contents 


IF 


THE OUTPUT file 


option, B IS NOT SET BREAKS OINtINS IS REQUIRED 
read in remainder of execution statement 
IF A Name is specified for the sdo output file 
set up a BUSE relationship i^ItH sdo 
ENDIf 

catalog and ASSIr.N $00 AS 
IF The catalog step failed 
Print an error message 
terminate The PROCESSOR 
<“—•**— EX ITPROCEOURE 
ENDIf 

^^^BREAkPOINT the output TO SOD 

"««i;c^Oc»-£Npent constants 

REAoJJni?^*^^ I U8*4*B8 CHARS/LINE) 

HRITE.UNit I J 

Default. indent ■ , 

RI6HT«HARG1N . gQ 

CHARACTERS 

ESTABLISH TQFEN .DICTIONARY DATA STRUCTURE 

<— eIitproceoure^^^’^^ establish default keywords 

enoproceoure 


771 

777 

777 

777 


777 
•>1 41 


line 

IBB 

1B9 

uo 

Ul 

1*2 

U3 

188 

181 

184 

187 

18B 

189 

170 

171 

172 

173 

178 
171 

174 
177 
17B 

179 
IBO 


procedure for keyhoro.set up 

LOOP Using the following data paIrs 

18 . pound sign in KEYNoRdS BELOW) 


PAGE 


Keyword 

•Mark*" 

•String 

•indent 

•linenumber 

•text 

•title 

•tNO 

•Define 

•eject 

•width 

•sequence 

•Terminate 


Procedure name 

sct,oata,chaR 
Set. STRING. char 
Set, indentation 
Set. linenumber 
•ox, TEXT 
•OX.TkXT 

End. control 
Define. WORDS 
eject.page 
sct.page.wiotn 
Card. sequencing 

BlINO.TERMInATOR 


BEGIN iteration 

I*** keyword into the toKcn, dictionary 
ENOlOOp' ^HO'tDURE NAME INTO PROGRAM. NAME OF THE ENTRY 
ENOPROCEDURC 


SI 

SI 

SI 

SI 

SI 

SI 

SI 

SI 

SI 

SI 

SI 

SI 
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•••••••••••••• HOOULE REFeRCNCC TREE 

LH PAiE 


1 

1 

objectives 

2 

2 

oataIstructure 

3 

3 

nain 

H 

S 

, initialization 

S 

A 

, • KEYN0RD.SET.UP 

A 

H 

• CeT.STATEHENT 

7 

• 

• token. finder 

B 

• 

• entable 

t 

• 

, KeTMORD.PROCESSOR 

10 

• 

• SoURtC.LISTER 

11 

• 

• HRAP.uP 


lOENTlFI 


hoduLe 
CROSS reference lisyins 


PACE 


OATA.STRUCTURE 

PACE Z PROCRaH OATA.STRUCTURE 

LINES 31i C2 
ENTABLE 

PACE 3 PROCRAH NAIN 

LINES 7) 

CET.5TATEHENT 

PACE 3 PROCRaH NAiN 

LINES 4A 

PACE H procedure: cet.statenent 

LINES to 
initialization 

PACE 3 PROCRAN NAlN 

LINES AH . , 

PACE S procedure FQR INITIALIZATION 

LINES 121 

retnoro.processon 

PACE 3 PROCRAN HAlN 

LINES 77 
KETN0R0.5ET.UP 

PACE S PROCEDURE FOR INITIALIZATION 

LINES ISS 

PACE A procedure for kcyworo.set.up 

LINES ISO 

HAlN 

PACE 3 PROCRAH KAiN 

LINES A3 
OBJECTIVES 

PACE 1 prograh objectives 

LINES lA 

source.listeb 

PACE 3 PROCRAH HAlN 

LINES B2 
token. FINDER 

PACE 3 PROCRAH NAiN 

LINES At 
WRAP. UP 

PACE 3 PROGRAH NAiN 

LINES B7 


3-9 



77-24 


UATA iTeHs 

CROSS reference listing page f 

I DENT 1 F lER^****^*^^^^*** ♦*♦♦♦*♦♦♦♦♦♦♦*♦♦*♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ ♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ 

BUFFERtCOUNT 

PAGE S procedure For 1 N l t I At I Z AT I Orj 
LINES IR7 
characters, PER, WORD 

PAGE s Procedure fqr initialization 

LINES IRA 

character*count 

PAGE 2 Program data. structure 

LINES R2 

continuation. Hark 

PAGE H procedure: 6£T. STATEMENT 

LINES 106. lOV 
default. indent 

PAGE 5 PROCEDURE FoR INITIALIZATION 

LINES ISO 
ERROR messages 

PAGE 3 PROGRAM HAiN 

LINES as 

PAGE S procedure F(jR INITIALIZATION 

LINES 125 
I;)LNTIF1ER 

PAGE 3 PROGRAM MAIN 

LINES 72 

IN0£NTATI0N*C0LUMN 

PAGE 2 program data. structure 

LINES 60 
INPUT. TEXT. buffer 

PAGE 2 program data. structure 

LINES 33 

PAGE H procedure: Get. statement 

LINES ? 1 , 10 |, 10 **, ll 3 , JIM, 117 
PAGE S PROCEDURE Fqr INITIALIZATION 

LINES 153 
LINE. number 

page 2 PROGRAM DATA. STRUCTURE 

LINES S3 
MODULE. STACtC 

PAGE 2 program OAT a. STRUCTURE 

LINES 56 

PAGE 3 PROGRAM MAIN 

LINES 79, 80 

PAGE ** Procedure: get. statement 

LINES 96 
NODE. name 

PAGE 2 PROGRAM DAT A. STRUCTURE 

LINES 59 
OPTION.B 

PAGE 5 procedure FQK INITIALIZATION 

LINES 123, 132 
OPTION. C 

PAGE 5 procedure ^'^)H INITIALIZATION 

LINES 12*t 
OPTION. E 
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DATA items 

CROSS REFCrcNcC LISTlNQ PA«C lO 

lOCMT I f I £R *♦♦*♦♦♦♦♦♦♦♦♦♦♦♦♦ 

PACE 5 Procedure por imiyulization 

LINES 12S 
OPTlONtK 

PACE S procedure POR INITIALIZATION 

LINES 12A 
OPTION. M 

PACE S procedure PqR INITIALIZATION 

LINES IZ7 
OPTION.P 

pace 5 procedure For initialization 

LINES ize 
option. R 

pace 5 procedure por initialization 

LINES 129 
OPTION. T 

PACE S procedure PoR INITIALIZATION 

LINES IJO 
PACE«NUMBER 

pace 2 program oata. structure 

lines 52 
PROGRAM. name 

PACE 2 program OATa. STRUCTURE 

LINES NS 

PACE 6 PROCEDURE POR KEYWORO.SET* Up 

LINES I7« 

READ. UNIT 

PACE 5 Procedure por initialization 

lines ins 
REPERENCE 

PACE 2 Program data. structure 

LINES 51 

PACE 5 PROCEDURE POR INITIALIZATION 

LINES |2N, 127* 12S. l29 
REPERENCE.LIST 

PACE 2 program OATA. STRUCTURE 

LINES N9 
RICHT.MARCIN 

PACE 5 procedure POR INITIALIZATION 

lines 151 

SOD 

PACE N procedure; get.statement 

LINES 97 

PACE 5 procedure POR INITIALIZATION 

LINES I3N, 135. 137, iN3 
text*lengtm 

/PAGE 2 program DATA. STRUCTURE 

LINES 37 

PAGE 3 Program main 

LINES A7 

page n procedure; Get.statement 

LINES 92, 102. 105, 109, 117, lie 
TEXT. pointer 

page 2 program data. structure 
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OATA ITeHS 


lOENT IF I£R ♦♦♦♦♦♦♦♦♦♦ ♦♦♦♦♦♦*♦ 


KEfERENCE LXSTINS 


FA6E II 


LINES ^3 

token«oictIonary 

pa«e 2 Program data, structure 

lines ho 

PAGE 3 program MAIN 

lines 73 

PAGE 5 procedure Fqr INITIALIZATION 

LINES ISH 

PAGE A Procedure for ketworo.set'Up 

LINES 177 
T0KEN»TYPE 

PAGE 3 program HAiN 

LINES 70, 72 
USABLE columns 

page H procedure: GeT^STATEMENT 

LINES 102, lie 
WRiTCtUNIT 

PAGE S procedure FqR INITIALIZATION 

LINES 1N9 


REVISIONS 

CROSS reference LISTING 
1 DENT IFIER^+^*^^**4^***^++*4++******^***»*4’*+**^**+^ 


PAGE 12 


PAGE 3 Program haIn 

lines aa 

PAGE *♦ procedure; get. statement 

LINES 90 

page a procedure For keyword. set. Up 

LINES 163, 1aHi 165, )66, ia 7, l6a« 169, i7q, 17i, 172, 173, l7H 


program poRtabilitt considerations 

cross reference listing page i3 

777 

page H PROCeoUnE; GeT. STATEMENT 

LINES 102; 113, IlH 

PAGE 6 Procedure fqr initialization 

LINES 1H6, H7, 1H8, iH9, I&3 
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routines ANO rUNCTIoNS 

CROSS REf^ERCNcE LISTING PAGE IR 


BLIND. TERHInATOr 

PAGE A PROCEDURE FOR KE YNORO.SET.UP 
LINES 17H 
box.text 

PAGE A PROCEDURE FqR XEYWURO.SET.Up 

LINES |A7, 1A8 
caro.sequencing 

PAGE A Procedure for keyword. set. up 

' LINES 173 

oefine.woros 

page a procedure For keyworo.set. up 

LINES 170 
EJECT. PAGE 

PAGE A PROCEDURE FOR KEYWORO.SET. Up 

LINES 171 
CNO.CONTROL 

PAGE A procedure For keyword, set. Up 

LINES lAt 

sct.data.char 

PAGE A PROCEDURE FqR KEYWORD, SET.Up 

LINES IAS 
set.inoentation 

PAGE A Procedure for keyworo,set.up 

LINES IAS 
SET,LINENUM6ER 

PAGE A procedure FOR KEYWORD, SET.Up 

LINES lAA 
SET,PAGE,WI0TH 

PAGE A PROCEDURE FOR KEYWORD, SET, Up 

LINES 172 
set,string,char 

PAGE A PROCEDURE Fqr KEYWORD. SET,Up 

LINES lAR 
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Example 2. Illustration of SDDL responses to sample input errors: 
As input (part 1): 


l{*DEriNE null procedure, E .OPROCEOuREi EXlTPROCEOURE b 

2: Select* case enoselect endif 

3:*define module Function end return 

h;«oefine block if always 

5;*oefine Block given, enodata, .yielding 

6:*define block gi ven, , ,us ing 

tiproceoure to illustrate the continuation Capabilities for input a 

e:oF long lines g for output of long lines 

9:loop 

lOILOOP again 
1 I ; IF NOW IS the time 
12:00 IT AS Best you can 
13:given Input arguments 

IRIINPUT I 
ISllNPuT 2 

ia:using Common variables 
17: item 2 
is; item 3 

19:yielding Return arguments 
2o: answer 

2I;ENDqATa for procedure interface 
22;SELeCT 15 not a keyword anymore 
23:«INdENt 20 COLUMNS from Now on 
2H : IF answer ■ AGAIN 
25;CYCuE 

26:elseif answer • Stop 

27;EXItPRocEOURE 

28:EXItPR0gKAm 

29:rcturn 

3o:else 

31 :exi tloop 

32: always 

33: IF A 

3M;lOOP B 

35J IF c 

36;loop d wraps arouno th£ Left margin because of tme deep indentation 

37:9IN0ENt ■ R 

39’ENDlOOP^^°*^ amount iS SET TO H BUt TH£ PROCESSOR WILL UNINOENT CORRecTlY 

ro:an if Statement will be closed by the processor 
HI :enoloop 

terminated BY THE TERMINATION DIRECtUVE 

*T 3 » ■ T t R M I N A TE 3 

HRIFINaLLY ENDPROGRAM closes the remaining open blocks 
hsiendprogram 

H6I«LINENUmBEr 
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As Input (part 2): 


1 JFUNCTION For it 

2 : 61 VcN 
3;F|RST INPUT 
MISECONO INPUT 

s:usin6 Global variables 

a: A 

7:b 

bivieloing Or returning Calculations 
9:answer 1 
io:answer 2 

llIENO DATA 

12:loop until done 
13;IF today is TUESDAY 
IHrTHIS MUST BE BELGIUM 

ISISERIOUSLY, folks iNoTIcE HOW THIS LINE IS SPLIT 

u:iF A line has a Pound sign « the processor 

17ILINeS up THE PART AFTER THE • AGAfNST THE RIGHT MARGIN 

leiTHE remainder of the Document will be 
19;WRApPED up by the end of file MaRk# 


Execution step: 

eSDDL»SDDL.SDDL 
«ADD SDDL«SDDL. INPUT 1 
ALINENUMBER 
€ADD SDDL«SDDL.INPUT2 
«FREE SDD. 

§SYM SDD., HOLD/HOLD, G930OA 
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As output: 


line 


7 

7 

10 

11 

12 

13 

H 

15 

1 * 

17 

le 

i» 

20 


PROfiNAH ^ STATe'^E'^T SURPLIeO BY PRqCeSSOR 

procedure to illustrate tme continuation Capabilities fon input of long 
5LINES 5 For output of long lines 
loop 

loop again 

IF Non is the tine 

DO IT AS Best you can................ ............ ^ 

given input arguments 

INPUT I 
INPUT 2 

USING common variables 
item 2 
item 3 

yielding return arguments 
answer 


21 enddata for Procedure interface 

22 select is not a KEYWORQ ANYMORE 

2N if answer ■ AGAIN 

25 — Cycle 

24 ELSEIF answer ■ STOP 

27 EXlTpROCEOURE 

28 Ex I TpRoGR AM 

2? Return 

*•••• ••• error incorrect module escape word 

30 else 

31 < ——EX ITlOOP 

32 Always 

33 IF A 

3N loop B 

25 IF C 

loo 

4P 0 wRAms AROUNO the LEFT MARGIN BeCaUSe OF T^E DEEP INDENTATION 
38 

GINOENTATION amount is Set to n but the processor will UNINOeNT correctly 

2’ EnO 

SLOOP 

‘‘0 , an 

GIF Statement hill be closed by the processor 


ENOIF - stmt supplied BY 

Rl ENoLoOP 

‘•2 Next, 3 structures are terminated by the te 

GRMinaTION directive 

MR finally eNOPROGRaM closes the remaining open blocks 

ENOlOOP • stHT supplied By PROCESSOR 
RS ENOPROGRAM 
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LiNe 

1 FUNCTION for it 

2 QIVCN 

3 FIRST INPUT 

H second INPJT 

5 USIn 5 aLOBAC VaRIaBlES 

6 A 

7 B 

8 yielding oh returning CaLcULA riot's 

9 answer 1 

10 answer 2 

ENOgiVen - stmt supplied 0T processor 

11 ENO data 


page 2 


line 

program - statement supplied by Processor 

12 LOOP Until done 

13 IF today is TUESOAT 

IN this must Be BELGIUM 

IS Seriously, folks 

IG IF A line Has a pound sign 

17 Lines up the part after the 

is the remainder qp the Document 

1’ wrapped up by tHe end op pile 

ENDIF - STMt supplied by processor 
eNDIF - STHT supplied by processor 
ENDlOOP - STMT supplied by processor 
ENOPROGRAM - StMT supplied By processor 


WILL Be 
MARK, 


page 


NOTICE HOW THIS LINe IS SPLIT 
the PROCESSOR 
against the right margin 
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SECTION IV 

USING THE SDDL PROCESSOR ON THE JPL U1108 
Since SDDL usage (except 

always involves large f Jhe processing and to 

“ f rr..r,.:T.U‘ 

primary operating ’ Qg®gxEr8 file cataloging and 

:: :r:3 

After the SDDL If procLsed and printed 


#SDDL«SDDL.SDDL[ .options] 

#ADD qual»file.ini 
§ADD QUAL*FILE.IN2 

eEOF 

eSf SDD . , HOLD/HOLD .G9300A 


[SDD-output-filename . ] 


Option 


f^ganing 


B 

C 

E 

K 

M 


R 

T 


SupPeases catalog an. Braagpcint operatlcna. All output 
tSr.lreotly to the terminal. 

suppreaaes data element Ureas reference tahlea. 

Suppresses £rror messages. 

suppresses generation of default ILeywords (e.g., PRO 
IF , etc . ) . 

suppreaaes llodule oroaa reference table. 

H naaa editing operation to supply missing 
Suppresses mvLation statements. 

£.age references on Module in 

suppresses module Reference tree. 

suppresses lable of contents. 


nrst command invoKes the f rt;rn%«rcised. 

"rl Tso has the option to supply Tihe^^ 

tha name SDD. is selected as t relationship 

none is given, the name onw , ^ j^ame, an EXEC o cuot i 

1 ^ T f* the user does supply .a-j kv the user. The 

tsTet “p^'edumlen'cing SDD. to the name supplied by 
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user-supplied output file name must end with a period, 
ncorrectly specified, the processor will write an error* 
terminate without processing the input. 


If it is 
message and 




#ASG,A SDD. or §ASG,UP SDD. 
§BRKPT PRINT$/SDD 


and begins processing the input stream. 


editing°co^ands''to rscratcr^nfcsiSS'! Tanrtr appropriate 

(«ADC SIMU,.) for axeoutlon whan tha prooaL“ ifnn^^^ad! 

EDITII(rcOHPLETEB°wlli'tppaIr^on"tha^t.^^"!°'^ REFERENCE 

aent to tha printar wlth\^ha^pp^o^mtT«^^^e:^^^^ 

Sample execution setup: 


#SDDL*SDDL.SDDL 
§ADD QUAL*FILE.IN 
§FREE SDD. 

§SYM SDD. , HOLD/HOLD, G 9 300 A 


The SDDL processor and 
contained in a read-only file 
are contained in this file: 


several user’s information elements are 
named SDDL«SDDL. The following elements 


SDDL«SDDL.SDDL 
SDDL »SDDL. INFO 
SDDL^SDDL.XQT 
SDDL "EDDL. INPUT 1 
SDDL*SDDL.INPUT2 
SDDL *SDDL. USERS 


Processor executable element 
User’s information memo 
Sample execution element 
Sample SDDL input element (part 1) 

Sample SDDL input element (part 2) 

Mailing list for SDDL information bulletins 
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